home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 3: Developer Tools / Linux Cubed Series 3 - Developer Tools.iso / devel / lang / lisp / gcl-1.000 / gcl-1 / gcl-1.0 / doc / compile-file-handling-of-top-level-forms < prev    next >
Encoding:
Text File  |  1990-01-19  |  9.9 KB  |  223 lines
  1. Forum:        Compiler
  2. Issue:        COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
  3. References:    CLtL pages 66-70, 143
  4. Category:    CLARIFICATION
  5. Edit history:   V1, 07 Oct 1987 Sandra Loosemore
  6.                 V2, 15 Oct 1987 Sandra Loosemore
  7.                 V3, 15 Jan 1988 Sandra Loosemore
  8.         V4, 06 May 1988 Sandra Loosemore
  9.         V5, 20 May 1988 Sandra Loosemore
  10.         V6, 09 Jun 1988 Sandra Loosemore
  11.         V7, 16 Dec 1988 Sandra Loosemore
  12.             (Comments from Pitman, change DEFCONSTANT, etc.)
  13.         V8, 31 Dec 1988 Sandra Loosemore
  14.             (CLOS additions, etc.)
  15.         V9, 23 Jan 1989 Sandra Loosemore
  16.             (remove the CLOS additions again)
  17. Status: Proposal CLARIFY passed Jan 89
  18.  
  19.  
  20. Problem Description:
  21.  
  22. Standard programming practices assume that, when calls to defining
  23. macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
  24. certain side-effects occur that affect how subsequent forms in the
  25. file are compiled.  However, these side-effects are not mentioned in
  26. CLtL, except for a passing mention that macro definitions must be
  27. ``seen'' by the compiler before it can compile calls to those macros
  28. correctly.  In order to write portable programs, users must know
  29. exactly which defining macros have compile-time side-effects and what
  30. those side-effects are. 
  31.  
  32. Inter-file compilation dependencies are distinct from, and not
  33. addressed by, this issue. 
  34.  
  35.  
  36. Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
  37.  
  38. (1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
  39.     within a file being processed by COMPILE-FILE, normally have
  40.     compile-time side effects which affect how subsequent forms in the
  41.     same file are compiled.  A convenient model for explaining how these
  42.     side effects happen is that the defining macro expands into one or
  43.     more EVAL-WHEN forms, and that the calls which cause the compile-time
  44.     side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
  45.     ...) form.
  46.  
  47. (2) The affected defining macros and their specific side effects are
  48.     as follows.  In each case, it is identified what users must do to
  49.     ensure that their programs are conforming, and what compilers must do
  50.     in order to correctly process a conforming program.
  51.  
  52.     DEFTYPE: Users must ensure that the body of a DEFTYPE form is
  53.     evaluable at compile time if the type is referenced in subsequent type
  54.     declarations.  The compiler must ensure that the DEFTYPE'd type
  55.     specifier is recognized in subsequent type declarations.  If the
  56.     expansion of a type specifier is not defined fully at compile time
  57.     (perhaps because it expands into an unknown type specifier or a
  58.     SATISFIES of a named function that isn't defined in the compile-time
  59.     environment), an implementation may ignore any references to this type
  60.     in declarations and/or signal a warning.
  61.     
  62.     DEFMACRO, DEFINE-MODIFY-MACRO: The compiler must store macro
  63.     definitions at compile time, so that occurrences of the macro later on
  64.     in the file can be expanded correctly.  Users must ensure that the
  65.     body of the macro is evaluable at compile time if it is referenced
  66.     within the file being compiled.
  67.      
  68.     DEFUN: DEFUN is not required to perform any compile-time side effects.
  69.     In particular, DEFUN does not make the function definition available
  70.     at compile time.  An implementation may choose to store information
  71.     about the function for the purposes of compile-time error-checking
  72.     (such as checking the number of arguments on calls), or to enable the
  73.     function to be expanded inline.
  74.      
  75.     DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
  76.     named by these forms have been proclaimed special.  However, it must
  77.     not evaluate the initial value form or SETQ the variable at compile
  78.     time.
  79.      
  80.     DEFCONSTANT: The compiler must recognize that the symbol names a
  81.     constant.  An implementation may choose to evaluate the value-form at
  82.     compile time, load time, or both.  Therefore users must ensure that
  83.     the value-form is evaluable at compile time (regardless of whether or
  84.     not references to the constant appear in the file) and that it always
  85.     evaluates to the same value.  
  86.  
  87.     DEFSETF, DEFINE-SETF-METHOD: The compiler must make SETF methods
  88.     available so that it may be used to expand calls to SETF later on in
  89.     the file.  Users must ensure that the body of DEFINE-SETF-METHOD and
  90.     the complex form of DEFSETF are evaluable at compile time if the
  91.     corresponding place is referred to in a subsequent SETF in the same
  92.     file.  The compiler must make these SETF methods available to 
  93.     compile-time calls to GET-SETF-METHOD when its environment argument is
  94.     a value received as the &ENVIRONMENT parameter of a macro.
  95.      
  96.     DEFSTRUCT: The compiler must make the structure type name recognized
  97.     as a valid type name in subsequent declarations (as for DEFTYPE) and
  98.     make the structure slot accessors known to SETF.  In addition, the
  99.     compiler must save enough information about the structure type so that
  100.     further DEFSTRUCT definitions can :INCLUDE a structure type defined
  101.     earlier in the file being compiled.  The functions which DEFSTRUCT
  102.     generates are not defined in the compile time environment, although
  103.     the compiler may save enough information about the functions to code
  104.     subsequent calls inline.  The #S reader syntax may or may not be 
  105.     available at compile time.  
  106.  
  107.     DEFINE-CONDITION: The rules are essentially the same as those for
  108.     DEFSTRUCT; the compiler must make the condition type recognizable as a
  109.     valid type name, and it must be possible to reference the condition
  110.     type as the parent-type of another condition type in a subsequent
  111.     DEFINE-CONDITION in the file being compiled.
  112.     
  113.     DEFPACKAGE:  All of the actions normally performed by this macro at load
  114.     time must also be performed at compile time.
  115.     
  116.  
  117. (3) The compile-time side effects may cause information about the
  118.     definition to be stored differently than if the defining macro had
  119.     been processed in the "normal" way (either interpretively or by loading
  120.     the compiled file).
  121.     
  122.     In particular, the information stored by the defining macros at
  123.     compile time may or may not be available to the interpreter (either
  124.     during or after compilation), or during subsequent calls to COMPILE or
  125.     COMPILE-FILE.  For example, the following code is nonportable because
  126.     it assumes that the compiler stores the macro definition of FOO where
  127.     it is available to the interpreter:
  128.     
  129.         (defmacro foo (x) `(car ,x))
  130.         (eval-when (eval compile load)
  131.             (print (foo '(a b c))))
  132.     
  133.     A portable way to do the same thing would be to include the macro
  134.     definition inside the EVAL-WHEN:
  135.     
  136.         (eval-when (eval compile load)
  137.             (defmacro foo (x) `(car ,x))
  138.             (print (foo '(a b c))))
  139.  
  140.  
  141.  
  142. Rationale:
  143.  
  144. The proposal generally reflects standard programming practices.  The
  145. primary purpose of the proposal is to make an explicit statement that
  146. CL supports the behavior that most programmers expect and many
  147. implementations already provide.
  148.  
  149. The primary point of controversy on this issue has been the treatment
  150. of the initial value form by DEFCONSTANT, where there is considerable
  151. variance between implementations.  The effect of the current wording is
  152. to legitimize all of the variants.
  153.  
  154.  
  155. Current Practice:
  156.  
  157. Many (probably most) Common Lisp implementations, including VaxLisp
  158. and Lucid Lisp, are already largely in conformance.  
  159.  
  160. In VaxLisp, macro definitions that occur as a side effect of compiling
  161. a DEFMACRO form are available to the compiler (even on subsequent
  162. calls to COMPILE or COMPILE-FILE), but are not available to the
  163. interpreter (even within the file being compiled).
  164.  
  165. By default, Kyoto Common Lisp evaluates *all* top level forms as they
  166. are compiled, which is clearly in violation of the behavior specified
  167. on p 69-70 of CLtL.  There is a flag to disable the compile-time
  168. evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do not make
  169. their definitions available at compile-time either.
  170.  
  171.  
  172. Cost to implementors:
  173.  
  174. The intent of the proposal is specifically not to require the compiler
  175. to have special knowledge about each of these macros.  In
  176. implementations whose compilers do not treat these macros as special
  177. forms, it should be fairly straightforward to use EVAL-WHENs in their
  178. expansions to obtain the desired compile-time side effects.
  179.  
  180.  
  181. Cost to users:
  182.  
  183. Since CLtL does not specify whether and what compile-time side-effects
  184. happen, any user code which relies on them is, strictly speaking,
  185. nonportable.  In practice, however, most programmers already expect
  186. most of the behavior described in this proposal and will not find it
  187. to be an incompatible change.
  188.  
  189.  
  190. Benefits:
  191.  
  192. Adoption of the proposal will provide more definite guidelines on how
  193. to write programs that will compile correctly under all CL
  194. implementations.
  195.  
  196.  
  197. Discussion:
  198.  
  199. Reaction to a preliminary version of this proposal on the common-lisp
  200. mailing list was overwhelmingly positive.  More than one person
  201. responded with comments to the effect of "but doesn't CLtL already
  202. *say* that somewhere?!?"  Others have since expressed a more lukewarm
  203. approval.
  204.  
  205. It has been suggested that this proposal should also include PROCLAIM.
  206. However, since PROCLAIM is not a macro, its compile-time side effects
  207. cannot be handled using the EVAL-WHEN mechanism.  A separate proposal
  208. seems more appropriate.
  209.  
  210. Item (3) allows for significant deviations between implementations.
  211. While there is some sentiment to the effect that the compiler should
  212. store definitions in a manner identical to that of the interpreter,
  213. other people believe strongly that compiler side-effects should be
  214. completely invisible to the interpreter.  The author is of the opinion
  215. that since this is a controversial issue, further attempts to restrict
  216. this behavior should be considered as separate proposals.
  217.  
  218. It should be noted that user-written code-analysis programs must
  219. generally treat these defining macros as special forms and perform
  220. similar "compile-time" actions in order to correctly process
  221. conforming programs.
  222.  
  223.